In communication networks, it is known to monitor data packets of traffic transmitted through the communication network, traffic based on the Internet Protocol (IP). For example, a technology referred to as “sFlow”, e.g., specified in RFC 3176 (September 2001) or the sFlow Version 5 memo by InMon Corp, Marc Lavine, Foundry Networks, available under http://www.sFlow.org (July 2004), may be embedded within network nodes, in particular switches and routers. The sFlow technology to allows for continuously monitoring application level traffic flows. This may be accomplished at wire speed and simultaneously on all interfaces of the respective network node.
In the sFlow technology, an sFlow Agent runs as part of network management software within the network node. The sFlow agent combines interface counters and flow samples into sFlow datagrams. The network node sends the sFlow datagrams an sFlow Collector, which is responsible for collecting sFlow datagrams from a plurality of network nodes running an sFlow Agent. At the sFlow Collector, the sFlow datagrams may be analyzed to produce a rich, realtime, network-wide view of traffic flows.
In typical scenarios, information carried in packet headers of the monitored data packets may be used as a basis for flow analysis. In this case, the sFlow Agent may extract a packet header from the monitored data packet and include it into the sFlow datagram. For controlling the extraction of the packet header portion, a parameter referred to as MaximumHeaderLength is configured, and a string having a length corresponding to this parameter is extracted from each monitored data packet. The MaximumHeaderLength is usually set sufficiently long so that all relevant information in the packet header is covered, irrespective of possible variations in the structure or contents of the packet headers.
For example, such variations in the structure or contents of the packet headers may occur in a transport network utilizing Segment Routing (SR), e.g., as described in the Internet-Draft “Segment Routing Architecture”, draft-ietf-spring-segment-routing-06 (Oct. 14, 2015). In the case of SR, a router calculates a forwarding path (list of segments) for a data packet and embeds this information into a Segment ID stack in the packet header. With increasing complexity of the calculated forwarding path, also the depth of the Segment ID stack increases and may thus vary from flow to flow. Further, the Segment ID stack also changes during the forwarding of the data packet. (Typically the depth of the Segment ID stack decreases by one when the packet is forwarded from one segment to the next segment of the forwarding path.)
To ensure that all the relevant information from the packet headers is extracted, the MaximumHeaderLength parameter needs to be configured sufficiently high, e.g., using a reasonably estimate for a maximum depth of the Segment ID stack and some additional margin. However if a given data packet contains a Segment ID stack of lower depth, the extracted packet header portion will also include unnecessary bytes which are then included into the sFlow datagram. This may result in inefficient usage of transmission bandwidth and/or processing resources. For example, in the case of IP/SR packet headers, a MaximumHeaderLength corresponding to 82 bytes may be needed when aiming at completely extracting the packet header of a data packet in which the depth of the Segment ID stack is 12 (i.e., includes 12 Segment IDs). On the other hand, the length of a packet header of a data packet in which the depth of the Segment ID stack is only one may be only 38 bytes, which means that 44 bytes of unnecessary information would be included into the sFlow datagram.
Accordingly, there is a need for techniques which allow for efficiently extracting header information from monitored data packets.